home *** CD-ROM | disk | FTP | other *** search
/ Collection of Tools & Utilities / Collection of Tools and Utilities.iso / olrdrs / soup12.zip / SOUP12.DOC
Text File  |  1993-08-17  |  40KB  |  839 lines

  1.            Simple Offline USENET Packet Format (SOUP) Version 1.2
  2.  
  3.               Copyright (c) 1992-1993 Rhys Weatherley
  4.  
  5.                     rhys@cs.uq.oz.au
  6.  
  7.                       Last Update: 14 August 1993
  8.  
  9. DISTRIBUTION
  10.  
  11. Permission to use, copy, and distribute this material for any purpose
  12. and without fee is hereby granted, provided that the above copyright notice
  13. and this permission notice appear in all copies, and that the name of Rhys
  14. Weatherley not be used in advertising or publicity pertaining to this material
  15. without specific, prior written permission.  RHYS WEATHERLEY MAKES NO
  16. REPRESENTATIONS ABOUT THE ACCURACY OR SUITABILITY OF THIS MATERIAL FOR ANY
  17. PURPOSE.  IT IS PROVIDED "AS IS", WITHOUT ANY EXPRESS OR IMPLIED WARRANTIES.
  18.  
  19. NOTE: This document is NOT in the public domain.  It is copyrighted.
  20. However, the free distribution of this document is unlimited.
  21.  
  22. If you create a product which uses this packet format, it is suggested
  23. that you include an UNMODIFIED copy of this document to inform your users
  24. as to the packet format.  All queries about this format, or requests for
  25. the latest version should be directed to Rhys Weatherley at the above
  26. e-mail address.
  27.  
  28. INTRODUCTION
  29.  
  30. For many years, the FidoNet community has been using QWK and other formats to
  31. enable users to download their mail and conferences to be read while off-line.
  32. This not only saves phone charges and prevents tying up BBS lines for long
  33. periods of time; it also allows a user to use much more powerful tools on
  34. their own machine to process the downloaded "packets" than what can be made
  35. available in an on-line environment.
  36.  
  37. To date however, very little work has been done in the USENET and dial-in Unix
  38. community to facilitate the same user operations.  Some attempts have been
  39. made to use QWK, but due to QWK's limitations and unsuitability for the USENET
  40. message formats, such efforts have not been very successful.
  41.  
  42. Within USENET, the tendency seems to be either "dial-in to some other machine
  43. and put up with it", or "set up your own USENET site".  The former keeps the
  44. user at the mercy of whatever user interfaces the admin of the other machine
  45. sees fit to install, and the latter requires far more computing knowledge than
  46. the average computer user is expected to have.  Both of these can serve to
  47. lock out large portions of the computer-literate public from experiencing
  48. USENET.  The latter option can also give rise to security problems in the form
  49. of forged USENET messages, which a more controlled dial-in system avoids.
  50.  
  51. The purpose of this document is to define a new packet format which is aware
  52. of the conventions used in the USENET community, forming a middle ground
  53. between dial-in user interfaces and full USENET connectivity.  It is not
  54. limited to downloading USENET news however.  The same format could be used
  55. to enable a Unix user to package up their Unix mailbox and download it for
  56. later perusal.  The format is extensible to other kinds of news or conference
  57. systems, so it is feasible, although not yet defined, that QWK or FidoNet
  58. messages could be accomodated within the same packet as USENET messages.
  59.  
  60. REVISION HISTORY
  61.  
  62. 1.2    Add COMMANDS and ERRORS files.  Renamed to "Simple Offline USENET
  63.     Packet Format".  A few extra fields and type codes for the AREAS and
  64.     LIST files.  Message area summaries.
  65.  
  66. 1.1    Add description of the LIST file.  Everything else is identical to 1.0.
  67.  
  68. 1.0    Original version of the document.
  69.  
  70. Previously, this document was known as the "Helldiver Packet Format" (HDPF).
  71. A variant of HDPF, called the "Simple Local News Packet format" (SLNP) was
  72. created by Philippe Goujard (ppg@oasis.icl.co.uk).  This document combines
  73. the features of both previous formats and the name was changed to make it
  74. less product-oriented.
  75.  
  76. TERMINOLOGY
  77.  
  78. Packet: a set of files, collected into a compressed archive.
  79.  
  80. Message packet: the primary kind of packet which contains messages for
  81.     the user to read.
  82.  
  83. Reply packet: a special kind of packet which contains replies composed by
  84.     the user, usually in response to the messages in a message packet.
  85.  
  86. Packet generator: a program which generates packets to be downloaded and
  87.     read, and which processes uploaded reply packets.
  88.  
  89. Packet reader: a program which reads packets, usually by presenting the
  90.     messages in a packet to the user, and which generates reply packets.
  91.  
  92. Packet processor: either a packet generator or a packet reader.
  93.  
  94. Generating host: the computer on which the packet generator executes.
  95.  
  96. Reading host: the computer on which the packet reader executes.
  97.  
  98. Download: the transfer of a packet from the generating host to the reading
  99.     host.  This transfer may take place in any fashion, although the
  100.     most common method is through the use of a file transfer protocol
  101.     such as Zmodem or Kermit.
  102.  
  103. Upload: the transfer of a packet from the reading host to the generating host.
  104.  
  105. Packet stream: a logical link between the generating and reading hosts over
  106.     which downloads and uploads of packets take place.
  107.  
  108. Message area: a collection of messages which are related by a common topic
  109.     or purpose.  Examples of message areas include USENET newsgroups,
  110.     Unix mailboxes, and FidoNet conferences.
  111.  
  112. Reply message area: a special kind of message area which contains replies
  113.     being uploaded to a generating host.
  114.  
  115. Text file: an ASCII file consisting of lines terminated by linefeed characters
  116.     (LF, 10 decimal).  Some operating systems terminate lines in a text
  117.     file by CRLF pairs: such files must be converted to LF-terminated
  118.     lines for transmission in a packet.
  119.  
  120. ANATOMY OF A PACKET
  121.  
  122. A packet is a group of files, collected into a compressed archive.  The
  123. standard compression technique defined by this document is ZIP.  Other
  124. techniques such as ARJ, ZOO, ARC, LZH, etc can also be used.  It is also
  125. possible for Unix's tar.Z format to be used to transmit packets.  The minimum
  126. requirement is a method to collect a group of files into a single packet,
  127. and a method to expand the packet back into the original files.  ZIP is
  128. specified to provide a common compression format for packet processors.
  129. Each of the filenames in a packet should be stored in upper case on those
  130. systems where case matters (e.g. Unix).
  131.  
  132. The following file specifications may appear in a packet:
  133.  
  134.     INFO        Optional textual information.
  135.     LIST        List of message areas on the generating host.
  136.     AREAS        Index of the message areas within the packet.
  137.     REPLIES        Index of the reply message areas from the reading host.
  138.     *.MSG        Text of the messages in a particular message area.
  139.     *.IDX        Index information for messages in a message area.
  140.     COMMANDS    Extra commands sent along with a packet.
  141.     ERRORS        Errors that occurred during the execution of commands.
  142.  
  143. Other filenames may also appear in the packet, but are not defined by this
  144. specification, so they should be avoided by generating software, and ignored
  145. by receiving software.
  146.  
  147. The INFO file is an optional text file which may contain any kind of textual
  148. information from the generating system.  Typically this file would only be
  149. present if there is some kind of urgent message that must be sent to the
  150. receiving user.  Use of this file to store the name of the generating host
  151. and other such static information is possible, but discouraged to save space
  152. and transmission time.  If such information is required, then the COMMANDS
  153. file can be used to transfer it.
  154.  
  155. The LIST file is an optional text file which contains a list of all message
  156. areas that are available on the generating host, together with the format of
  157. the messages.  It is specified further in the section "LIST FILE".
  158.  
  159. The AREAS file is a text file which contains an index of the message areas
  160. present within the packet, specifying the name of the message area, the
  161. filename the messages may be found in, and the message format.  This is
  162. specified further in the next section.
  163.  
  164. The REPLIES file is a text file which contains an index of the message areas
  165. present within the packet that contain replies from the user which should
  166. be mailed or posted on the generating host.  In most cases, a packet will
  167. contain either an AREAS file or a REPLIES file, but both may be present.
  168. See the section "REPLIES FILE" below for more information.
  169.  
  170. The *.MSG files contain